home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / April 96 / Re ODF usage restrictions < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  1.6 KB  |  [TEXT/ttxt]
  1. Subject:     Re: ODF usage restrictions
  2. Sent:        4/17/96 4:39 AM
  3. Received:    4/17/96 7:01 AM
  4. From:        Serge Froment, sfroment@odyssee.net
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >   The ODF documentation, when last I read it, contained the caveat that
  9. >ODF could be used with no restrictions as long as it was for Macintosh or
  10. >Windows development. I am not sure if this has been brought up before, but
  11. >I personally don't want any restrictions on what operating systems I am
  12. >able to port to in the future (as long as I'm willing to do the work to
  13. >port the framework to another operating system, I should be able to use
  14. >it).
  15. >
  16. >   Effectively, adoption of ODF for a project will lead to code which has
  17. >ODF code and concepts intrinsically embedded within it. This would make for
  18. >an _extremely_ unpleasant rewrite if one had to port to an environment
  19. >within which use of ODF was not allowed -- porting the framework ourselves
  20. >would actually be a more pleasant prospect.
  21. >
  22. >   Is there any way we can get blanket approval for use of ODF on all
  23. >platforms? (if not, why not, and exactly what guarantees _do_ we have?)
  24.  
  25.  
  26. Henri,
  27.  
  28. I have exactly the same concerns. When pushing OpenDoc projects inside my
  29. company, I was advocating to my boss that ODF is the best framework I have
  30. seen so far, and if we want to support a platform not yet supported by ODF,
  31. we could port the framework as easily as if it were our own code.
  32.  
  33. I think I understand why Apple sets this restriction, but I feel a solution
  34. that fulfill both Apple and Developers interest sould be found.
  35.  
  36. Serge
  37.  
  38.